home *** CD-ROM | disk | FTP | other *** search
/ Internet Warrior 1993 July / Internet Warrior No. 1 July 1993 - Austin Code Works.ISO / docs / internet / format.inf / text0000.txt < prev   
Encoding:
Text File  |  1992-12-27  |  8.9 KB  |  204 lines
  1. Checksum: 4219959243  (Verify with "brik -cv")
  2. Posting-number: Volume 03, Issue INF4
  3. Submitted-by: Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
  4. Archive-name: v03info/format.inf
  5.  
  6. [ Written by Rahul Dhesi, Mon Feb 13 13:29:37 EST 1989.  Last change
  7. from Rahul Dhesi, Sun Mar 19 00:59:55 EST 1989 ]
  8.  
  9.                             FORMAT OF POSTINGS
  10.  
  11. All postings in comp.binaries.ibm.pc include a set of headers at the
  12. beginning in a standardized form.  There are two sets of headers.  The
  13. first set of headers is separated from the second set, and the second
  14. set is separated from the rest of the posting, by an empty line.  The
  15. first set conforms to the format used by the news transport and reading
  16. software.  The second set is not used by the news software but provides
  17. information that may not be available in the first set of headers.
  18.  
  19. FIRST SET OF HEADERS
  20.  
  21. The From: header is always an electronic mail address of the person who
  22. submitted this posting to comp.binaries.ibm.pc.  Whenever available,
  23. this address is in domain format.  If no domain address was available,
  24. it is in the format "user@host.UUCP".  If the second format was used,
  25. look elsewhere in the posting for suggestions about possible UUCP paths
  26. to use.  Whenever possible, the address is accompanied by the name of
  27. the person.
  28.  
  29. The Subject: header is in one of the following forms:
  30.  
  31.      Subject: vxxiyyy: name, description
  32.      Subject: vxxiyyy: name, description (part mm/nn)
  33.      Subject: vxxINFy: name, description
  34.      Subject: vxxJUNK: description
  35.  
  36. The "vxxiyyy" means "Volume xx, Issue yyy".  The Volume number changes
  37. approximately once every 100 issues.  The issue number changes with
  38. each posting.  Large submissions are broken up into smaller pieces, and
  39. a single submission will then correspond to several issue.  In this
  40. case the "part mm/nn" identifies each part of a multi-part posting, and
  41. "mm/nn" means "part mm of a total of nn parts".  In rare cases, when an
  42. unimportant administrative posting appears, it will use the last form,
  43. in which "vxxJUNK" means "junk in volume xx".
  44.  
  45. Occasionally a multi-part posting will be preceded by a part 0 which
  46. describes the parts that follow.
  47.  
  48. Certain informative articles, such as the one you are reading now, are
  49. periodically posted to introduce the user this newsgroup, explain how
  50. to get software from it, how to submit software to it, etc.  These
  51. postings have a Subject header of the third type, in which "vxxINFy"
  52. means "periodic informative posting y in volume xx".
  53.  
  54. The Summary: header is of the form:
  55.  
  56.      Summary: filename, description
  57.  
  58. The "filename" is the filename in which this posting will be found
  59. after it has been extracted as appropriate.  (Extraction will usually
  60. involve combining multiple parts if any and then uudecoding.)   The
  61. "filename" is intended to be legal under MS-DOS 2.x, MS-DOS 3.x, System
  62. V and 4.xBSD.  The "description" usually duplicates the description
  63. given in the Subject:  header except that part numbers are not given.
  64.  
  65. The Keywords: header is added to some postings to mark them as
  66. special.  This header is followed by a comma-separated list of
  67. keywords.  Currently, the keywords in use are:
  68.  
  69.      administrivia             An administrative announcement
  70.      discard                   A posting that can be discarded soon after
  71.                                it has been read, so it need not be archived
  72.      info                      An informative posting;  similar to
  73.                                administrivia, but of greater scope
  74.  
  75. Administrative postings of fleeting importance are marked with both the
  76. "administrivia" and "discard" keywords.  It is probably safest to
  77. archive all postings that do not include the "discard" keyword.
  78.  
  79. SECOND SET OF HEADERS
  80.  
  81. The Checksum: header is of the form:
  82.  
  83.       Checksum: 1733847567
  84.  
  85. This header may be used to verify the integrity of the article as it
  86. arrived at your site.  The checksum is really a 32-bit CRC (cyclic
  87. redundancy code) generated with the program "brik", which was posted in
  88. comp.binaries.ibm.pc as C source and MS-DOS executable in volume 1,
  89. issue 217, 14 March 1989.  To verify the integrity of any article in
  90. comp.binaries.ibm.pc, supply it to brik as a filename on the command
  91. line or as standard input.  For example, from rn, you can type
  92.  
  93.      | brik -cv
  94.  
  95. and if brik prints no error message, it means that the CRC calculated
  96. by brik matched the one stored in the article.  You can also save the
  97. article in a file, e.g. a file called this.article, and then give the
  98. command:
  99.  
  100.      brik -cv this.article
  101.  
  102. to check the CRC.
  103.  
  104. The Posting-number: header is of one of the forms:
  105.  
  106.       Volume xx, Issue yyy
  107.       Volume xx, Issue INFy
  108.       Volume xx, Issue JUNK
  109.  
  110. This verbosely duplicates the information in the "vxxiyyy", "vxxINFy",
  111. or "vxxJUNK" field found in the Subject: header.
  112.  
  113. The Originally-from: and Submitted-by: headers tell you where this
  114. posting originated and who submitted it to this newsgroup.  The
  115. Originally-from: header is optional and is added only if it provides
  116. information that is not in the Submitted-by: header.  The
  117. Originally-from: header identifies where the submitter got the
  118. software, or who wrote it, or both.  The Originally-from: header will
  119. not always mean the same thing, but is simply an attempt to provide
  120. more information than the Submitted-by: header alone provides.
  121.  
  122. The Submitted-by: header identifies who submitted the posting to this
  123. newsgroup.  If you have questions about a posting (rather than the
  124. software itself), the person identified in this header is usually the
  125. one to contact.  Due to the possibility of the news software mangling
  126. headers of articles, the Submitted-by: header is likely to be more
  127. reliable than the From: header.
  128.  
  129. Both the Originally-from: and Submitted-by: headers provide a domain
  130. format electronic mail address if one is available, else they provide
  131. an address of the form user@host.UUCP or host1!host2!...!user.  Where
  132. possible any UUCP address is shown relative to a well-known site, or
  133. additional hints for contacting the person are given in the text
  134. following the header.
  135.  
  136. The Archive-name: header is intended to be used for the automated (or
  137. manual) archiving of postings.  The format of the string following is
  138. always "dirname/filename" where "dirname" is a suggested directory name
  139. and "filename" is a suggested filename for storing this specific
  140. posting.  In the case of a multi-part posting each part will have the
  141. same "dirname" but a different "filename".  Both the "dirname" and
  142. "filename" are legal directory or file names under MS-DOS 2.x, MS-DOS
  143. 3.x, System V, and 4.xBSD.  The filename is often, but not always, of
  144. the form "partxx" where xx is a two-digit number.
  145.  
  146. The Can-delete: header is occasionally added when a posting supersedes
  147. an earlier one, for example, when a new version of software is posted
  148. and the old one becomes obsolete.  Only the Can-delete: header in the
  149. FIRST part of a multi-part posting is intended to be used in this way,
  150. although it may be present in other parts too.  The Can-delete: header
  151. is in the form of "dirname/filespec" such that "dirname" is a directory
  152. name, and "filespec" is a filespec that may possibly contain wildcards
  153. acceptable to the C-shell.  The Can-delete: header is a recommendation
  154. from the moderator that matching files can be deleted because they are
  155. obsolete.
  156.  
  157. If necessary, the Can-delete: header may occur more than once, or
  158. contain multiple filenames, to suggest deletion of multiple files.  For
  159. example,
  160.  
  161.      Can-delete:  xyz/src0[1-3]  abc/exe[135]
  162.      Can-delete:  xyz/exe0[1-2]
  163.  
  164. means that xyz/src01, xyz/src02, xyz/src03, abc/exe1, abc/exe3,
  165. abc/exe5, xyz/exe01, and xyz/exe02 may all be deleted.
  166.  
  167. This header should NOT be used for the automatic deletion of files, as
  168. I cannot guarantee that I will never make any mistakes.  Do all
  169. deletions manually.
  170.  
  171. MODERATOR'S COMMENTS AND CHECKSUMS
  172.  
  173. Most postings are accompanied by moderator's comments.  These are
  174. enclosed in brackets [...].  If during testing I find bugs that are not
  175. serious enough to prevent the software from being useful, I simply
  176. describe them in my comments.  The thoroughness with which I test
  177. software before it is posted varies.  I try to test every submission,
  178. but some occasionally get posted with little or no testing.
  179.  
  180. Each single-part posting, and part 1 of each multi-part posting,
  181. contains a list of checksums.  These are calculated using the 4.3BSD
  182. "sum" command.  To get the same answer use "sum -r" under System V.
  183.  
  184. Checksums for uuencoded postings are always for all the lines between,
  185. but not including, the BEGIN and END lines.  To find this checksum
  186. easily you can filter a posting through the following shell command
  187. line:
  188.  
  189.      sed -e '1,/^BEGIN/d' -e '/^END/,$d'| sum
  190.  
  191. (use "sum -r" instead of "sum" under System V).
  192.  
  193. The checksum for a file that you would get after uudecoding is for the
  194. entire file.
  195.  
  196. The format in which checksums are given in the body of a posting is not
  197. yet standardized.  It is due to be revised soon to make it more
  198. compact, and to make it easier to automate the testing of checksums.
  199.  
  200. Also provided is file size in bytes.
  201. -- end of format.inf --
  202.  
  203.  
  204.